The front ends of most business applications presents and accepts information in a user-friendly fashion. A business application is typically designed with a graphical user interface (GUI) that displays information by mimicking something a user is accustomed to seeing and working with, such as a business form, a shipping label, or a questionnaire. Beneath the GUI level, however, the information may be organized far differently than its manner of display might suggest. For example, displayed information may be organized into several object oriented programming (OOP) objects, which may, in turn, have several OOP objects dependent on, related to, or connected to them, for example via method calls. Further and at a more basic level, each of the OOP objects may store its data in several different database rows contained in several different database tables, and this data may be interdependent, interrelated, or interconnected in some manner, for example, through shared data, shared tables, foreign keys, etc.
These layers of objects and their associated database entries are difficult to correctly update and maintain because any relevant interrelated and interdependent objects (and thus their underlying database data) should be changed as needed for consistency whenever an object is changed. Similarly, changes to an object and its data should be prevented if relevant interrelated and interdependent objects and data cannot be changed as needed to maintain synchronization between related objects and data. This is difficult to do in systems where the user, and to a lesser extent the front end application, typically has no awareness of the layers of objects and database entries connected to the information displayed, entered, and manipulated on the GUI. For example, in service-oriented architectures, the front end application typically interacts through service requests with a backend that maintains the objects and databases. The services are typically self-contained and do not depend on the context or state of the other services and thus may access the same underlying objects and databases used by other services at the same time as other services, destroying the synchronization among objects and among data.
Database transaction processing systems face a somewhat similar problem where a single transaction can update many different databases. Such systems often use a two-phase commit to help address the problem, which enables the databases to be returned to the pre-transaction state if some error condition occurs. The two-phase commit strategy is designed to ensure that either all the databases are updated or none of them, so that the databases remain synchronized. In a two-phase commit, database changes required by a transaction are initially stored temporarily by each affected database. The transaction monitor then issues a “pre-commit” command to each database which requires an acknowledgment. If the monitor receives the appropriate response from each database, the monitor issues the “commit” command, which causes all databases to simultaneously make the transaction changes permanent. Otherwise, all the temporarily stored changes are rolled back and discarded. The two-phase commit strategy, however, only applies to the database operations that are part of a transaction, which are not based on relationships between OOP objects. Thus, a two phase commit does not solve all the problems associated with multidatabase transactions. For example, it does not address finding and changing additional objects and database entries that are related to or dependent from another object.
Accordingly, it is desirable to provide systems and methods for finding and changing objects (and their underlying data), that are related to or dependent on an object that is changed by a user application, maintaining consistency among all the related objects and their associated data. It is also desirable to provide a clear framework defining the times at which object-modifying services can be requested and the times at which object-modifying services must be provided.